home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / letters_fj / text0002.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  4.7 KB  |  116 lines
  1. Hi again,
  2.  
  3. > Same for me. I started when I was ten years old, on the school's TRS-80.
  4.  
  5. I was ten as well. It was a bit difficult to get started earlier back then.
  6. Not even the original PC existed IIRC (not that that was a bad thing).
  7.  
  8. > Quickly I got a TI99, and then an ATARI800XL. And then,naturally enough, I
  9.  
  10. I very nearly bought a TI99/4A, but given their history I was lucky.
  11. The Sinclair QL was mere chance, since I'd decided on a Spectrum 48. But
  12. when I was looking around the shops in London (on a summer trip) for the
  13. best price, my father suddenly got the idea that he'd have a use for a
  14. computer...   ;-)
  15.  
  16. > science and physics. I didn't want to do only one thing all my life, so I
  17. > chose Physics. Never regretted it!
  18.  
  19. :-)
  20.  
  21. > I think assembly language is the reasonable choice. We will need all the
  22. > power we can get.
  23.  
  24. For a lot of things I really think we should use GCC. It produces very good
  25. code (but far from usable for graphics of course) and there is likely to be
  26. a _lot_ of general house keeping and such.
  27. For MGIF I write everything in C at first and then optimize the most speed
  28. critical parts (mainly GIF loader and various chunky to planar conversions)
  29. by rewriting them in assembly. That way it's quick to get it all working.
  30. I still keep all the original C code in the sources for the future.
  31.  
  32. C++ as in dview is probably not a good idea, though, since virtual memory
  33. would likely be needed to compile the program. I run Outside all the time,
  34. but I don't know how common that is.
  35.  
  36. > >But perhaps that's not too complex in DOOM either.
  37. > Nono. But anyway, to be compatible with the WADs doesn't oblige us to have
  38. > the same AI for the monsters, who are anyway quite dumb: as soon as they
  39. > have spotted you, they follow you and try to shoot you. Unfortunately for
  40.  
  41. I've played quite a lot of DOOM on the Jaguar and the monsters are not
  42. quite that single minded, but close enough.
  43. Having smarter monsters could be fun, but it could also make many levels
  44. totally impossible.
  45.  
  46. > BTW, I think we will include the same cheat modes...
  47.  
  48. Yes, but DOOM really is a much nicer game without them. I especially like
  49. the Jaguar version were you can't save. Starting out with only the pistol
  50. on some of higher levels is _extremely_ 'interesting'. I know you can do it
  51. that way on the PC as well, but I've never met anyone who ever did.
  52. (I've reached the second to last level on 'Ultra violence', but some of
  53.  the later levels were __though__!.)
  54.  
  55. > >pity DOOM is mostly 2D.
  56. > No it's not a pity, because this way, it becomes a lot faster, so that we
  57.  
  58. It _is_ a pity that I won't be able to do any 3D work.  :-(
  59.  
  60. > can port it on atari. I don't think it would be reasonable to make a Descent
  61. > clone on atari, would it? So the 2D aspect suits me fine.
  62.  
  63. Without the texture mapping, I think Descent would be doable. Certainly not
  64. as fast as a non-textured DOOM, but not too bad either.
  65.  
  66. > >Sure it should (probably) be done sooner or later, but I'm a strong
  67. > >believer in adding more stuff after the basic functionality (in this case
  68. > >a graphics engine of useful speed) is there.
  69. > Usually it's of course the best way to work for an individual programmer.
  70.  
  71. Yes, but in this case I think we should get _something_ out ASAP. If we can
  72. show people that a Falcon DOOM is feasible, there will probably be a lot of
  73. help coming from various places. We could move on to other things while the
  74. basic stuff gets improved.
  75.  
  76. > Here, there are several very distinct "modules" to be developped, and then
  77. > brought together: the 3D engine, scaled sprites, sounds, music,
  78. > communication, and the management of the universe (to move the monsters, the
  79. > player, manage the weapons and so on)
  80.  
  81. The '3D' engine probably has to be very closely connected with the sprites.
  82. Granted, they can't be in the BSP tree, but they must probably use the same
  83. data structures to be drawn correctly.
  84.  
  85. I believe, though, that it would be a good idea to sub-divide the graphics
  86. engine somehow. I've not looked at dview yet, so I don't know how complex
  87. it really is.
  88.  
  89. Is the sound in DOOM directional? If not it should be very simple to add.
  90. (The sound that is, not the directionality.)
  91.  
  92. Regarding the music, I'm not so sure we should actually bother. On the
  93. Jaguar there's no music in DOOM and it doesn't matter a bit IMO.
  94.  
  95. The world updating is certainly a separate module.
  96.  
  97. > Each of these modules can be developed and tested independantly.
  98.  
  99. Yes.
  100.  
  101. > >> Wish to hear from you soon,
  102. > >Was this soon enough?   ;-)
  103. > Yes. And this?
  104.  
  105. Not bad!  ;-)
  106.  
  107. Regards,
  108. Johan
  109.  
  110. -- 
  111.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  112.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  113.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  114.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  115.  
  116.